1. Field of the Invention
The present invention relates generally to computer software and operating systems. More specifically, it relates to an interface for a Java virtual machine that enables more efficient use of components in the virtual machine and allows for efficient invocation of native methods.
2. Discussion of Related Art
The need to place a Java system or Java virtual machine (“JVM”) in consumer and embedded systems is increasing. Devices, appliances, set-top boxes and the like are more likely in the future to contain some kind of implementation of the Java language. As is known in the field, a typical implementation of the Java language is a JVM, containing an interpreter loop (also referred to as a bytecode interpreter) which repeatedly executes bytecodes. The interpreter loop is typically written in a low-level language, such as the C programming language, and executes a stack-based intermediate representation of the Java language called Java bytecodes. A Java system, such as one present in an embedded or consumer device, typically contains a set of libraries written in Java and a set of native methods, written in a language such as C. For Java bytecodes to call native methods, a native method interface is provided by the virtual machine. This native interface is responsible for locating a native method and transferring a set of method arguments from the Java bytecode stack to a native stack (also referred to as a C stack) before execution of the native method. The interface is also responsible for taking a native method's return value and putting it back on the Java stack for subsequent use by Java bytecodes. Essentially, the native method interface takes arguments from the Java stack and places them on the C stack. A common native method interface for Java is the Java Native Interface or JNI.
Other issues arise when using present native method interfaces on systems with limited CPU and memory resources. One issue is that many performance-critical native methods must be run often. However, the native method interface “protocol” takes excessive time for execution. In addition, the native method returns to the interpreter loop, a frame needs to be popped from the Java stack. Another issue is the amount of space utilized by the native stack or C stack. For special method calls, namely, method invocations due to Java reflection (Method.invoke( ) and running constructors for Class.newInstance( )) and running the static initializer <clinit> of a class on the class's first use, there is a native stack usage problem. The C functions that handle the reflection method invocation and <clinit> method invocation recursively call the (Java) interpreter loop to execute the special target method. This means the native stack has a new interpreter frame pushed onto it. This process can go on indefinitely, from interpreter loop to native code to interpreter loop and so on. This recursive call cycle can potentially consume excessive C stack resources and processor clock cycles since the C stack is typically pre-allocated and made sufficiently large to avoid overflow in a worst-case scenario. This overhead for pre-allocating a C stack memory for accommodating a worst-case scenario for stack usage is significant for consumer and embedded devices executing a JVM that have constrained memory and processor resources. Therefore, if recursive C calls contribute to worst-case C stack usage, and those recursive calls can be reduced or eliminated, then worst-case C stack usage can be potentially reduced, thus allowing the size of pre-allocated C stacks to be reduced.
What is needed is a special-purpose native interface that allows a JVM to minimize the amount of memory and processor resources the JVM consumes. In certain cases, the special-purpose native interface used in conjunction with the interpreter loop can potentially eliminate C recursion. In addition, it would be desirable to effectively extend the interpreter loop in a JVM without adding one or more new bytecodes and by allowing certain native methods to directly manipulate or access the JVM state. More specifically, what is needed is a native interface that does not require pushing or popping Java frames, does not require marshaling arguments and method results between the Java and native stacks, and does not require expensive functions callbacks in order to allow the native method to access internal JVM data.